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I .    INTRODUCTION 

A.  PURPOSE  OF  THESIS 

The  purpose  of  this  research  is  to  design  a  prototype 
Graphical  User  Interface  (GUI)  for  Co-oP,  a  Group  Decision 
Support  System  (GDSS)  for  Cooperative  Multiple  Criteria  Group 
Decision  Making.  This  user  interface  will  substantially 
increase  the  value  of  the  Co-oP  model,  "...as  an  experimental 
tool  to  evaluate  the  effectiveness  of  group  Decision  Support 
Systems  in  supporting  group  decision-making."  [Ref.  l:p.  3], 
by  developing  an  effective  user- friendly  interface  that 
encourages  broadened  user  participation. 

B .  BACKGROUND 

Co-oP  was  designed  to  study  the  possibility  of  creating  a 
GDSS  that  supports  both  content -oriented  and  process -oriented 
decision  techniques  [Ref.  l:p.  117].  Furthermore  it  was  to 
provide  users  with  a  communications  network  in  order  to 
support  a  distributed  GDSS  by  setting  up  communications 
parameters  and  group  norm  definitions  prior  to  initiating  the 
group  decision  process. 

1.   System  Overview 

Co-oP  is  intended  to  be  a  microcomputer-based  process - 
driven  DSS  in  which  each  participant  of  the  group  has  his  own 
DSS  whose  model  base  is  based  on  multiple  criteria  decision 


methods  (MCDM)  along  with  additional  personal  DSS  tools  [Ref . 
l:p.  118]  .  The  GDSS  contains  sets  of  aggregation  preferences 
techniques  and  consensus  seeking  algorithms  that  can  be  used 
with  individual  MCDMs .  The  microcomputer  network  system  is  to 
be  linked  together  using  Local  area  network  [Ref.  l:p.  118]. 
Originally  written  in  Turbo  Pascal,  a  number  of  the  Co-oP 
routines  have  been  updated  to  C  in  1987.  In  order  to  follow 
an  unambiguous  and  uniform  flow  of  information,  Co-oP  follows 
the  basic  steps  of  a  multiple  criteria  problem  solving  process 
(see  Chapter  II,  section  C.l).  First,  the  group  must  select 
and  identify  a  decision  problem.  This  includes  determining 
the  set  of  alternatives  along  with  evaluation  criteria. 
Secondly  the  group  must  identify  members  and  set  communication 
parameters.  These  parameters  include  data  transfers, 
interactive  conversation,  utilization  of  electronic  mail,  and 
types  of  decision  techniques  [Ref.  l:pp.  121-124].  The  third 
step  involves  individual  evaluation  prioritization.  This 
includes  methods  of  assigning  weights  to  criteria  directly, 
for  example  ELECTRE,  or  using  a  hierarchical  prioritization 
scheme  (e.g.,  Analytical  Hierarchy  Process).  These  methods 
can  be  utilized  in  a  pooled  mode  in  which  all  group  members 
collectively  enter  a  priority  vector,  or  as  single  user  DSS 
with  communication  support.  The  fourth  process  allows  users 
to  individually  evaluate  alternative  using  his  preferred  or 
familiar  MCDM.  In  the  current  version,  these  methods  include 
ELECTRE,   the   Analytical   Hierarchy   Process,   or   direct 


individual  ranking.  The  next  step  of  the  process  is  the 
computation  of  group  results  using  four  techniques  of 
aggregation  of  preferences.  If  unanimity  is  not  obtained,  a 
consensus  seeking  algorithm  can  be  evoked  or  the  decision 
makers  can  revise  their  individual  evaluations. 

2 .   Model  Components 

The  main  purpose  of  the  MCDM  model  bank  is  to  provide  the 
decision  makers  a  set  of  models  that  can  solve  the  most  common 
types  of  decision  problems  [Ref.  l:p.  126].  Co-oP  contains 
three  models  that  cover  selection,  ranking,  and  sorting. 
These  methods  are  not  difficult  and  interact  with  techniques 
of  aggregation. 

The  ELECTRE  method  is  characterized  by  circumventing  the 
problem  of  incomplete  comparability  of  alternatives  through 
the  concept  of  outranking  relations  [Ref.  l:p.  127].  Two 
reasons  a  decision  maker  finds  it  difficult  to  compare 
alternatives  are  the  to  uncertainty  associated  with 
measurements  and  evaluation,  and  incomparable  alternatives. 

The  Analytic  Hierarch  Process  (AHP)  method  supports 
complex  decision  problems  by  successively  decomposing  and 
synthesizing  various  elements  of  a  decision  situation  [Ref. 
l:p.  131]  .  AHP  permits  subjective  and  qualitative  comparisons 
by  measuring  levels  of  priority  in  a  pairwise  relation, 
creating  a  reciprocal  matrix  of  pairwise  comparisons. 


3 .  Communications  Module 

Co-oP  provides  for  the  following  functions:  coordinate 
information  exchange,  enforce  communication  protocols,  search 
for  data  compatibility  for  group  algorithms,  and  sort  data  for 
diffusion  [Ref .  l:p.  136] .  A  group  norm  constructor  in  Co-oP 
allows  users  to  define  a  framework  for  communications  exchange 
in  support  of  the  decision  making  process.  The  group  users 
through  the  group  norm  agrees  upon  decision  techniques, 
techniques  of  aggregation  and  which  weighted  majority  rule  to 
be  complied  with.  Information  exchange  parameters  such  as 
broadcasting  of  outputs  to  selected  users  are  supported.  The 
group  norm  allows  users  to  modify  individual  inputs  and  also 
sets  a  time  limitation  in  which  to  submit  inputs.  In 
addition,  a  bulletin  board  or  electronic  notepad  can  be  used 
as  a  format -free  mechanism  for  group  members  to  exchange 
ideas.  To  protect  information,  password  identification  is 
required  by  members  of  the  group  norm. 

4 .  Interface  Component 

The  Co-oP  interface  was  designed  to  provide  a  simple 
unambiguous  and  standard  man-machine  interface  allowing  users 
to  concentrate  on  the  core  of  the  problem  [Ref.  l:p.  140]. 
During  the  problem  and  group  norm  definition  phases,  a  outline 
form  data  entry  format  is  used.  In  the  Pascal  version  of  Co- 
oP,  a  typical  screen  format  displays  four  different  windows 
simultaneously.   The  Step  window  identifies  current  process 


and  displays  any  required  diagnostic  messages  or  prompts.  The 
Dialogue  window  provides  a  conversational  medium  utilizing  a 
Question/Answer  mode  of  interaction.  The  Working  window 
displays  vital  information  from  dialogue  or  inputs  and 
displays  other  group  members  results.  The  Solution  window 
displays  immediate  and  final  results  in  the  format  of  tabular 
outputs,  graphs,  and  statistical  indexes.  Co-oP  also  utilizes 
different  colored  screens  and  text  to  allow  easy  recognition 
of  various  displays.  In  order  to  provide  the  users  with  a 
structured,  simple  and  controlled  framework  for  the  model,  Co- 
oP  combines  menus  and  questions  for  communication  with  users. 

C.  SCOPE  OF  RESEARCH 

The  scope  of  this  research  includes  the  prototype  design 
of  a  user  interface  for  the  Co-oP  Group  Decision  Support 
System  model  utilizing  a  programming  system  for  Windows 
environments.  Interface  design  is  patterned  on  current  GUI 
standards.  Individual  screen  designs  will  be  discussed  in 
depth  as  to  their  design  methodology  in  relation  to  the  Co-oP 
model . 

D.  THESIS  ORGANIZATION 

Chapter  II  reviews  general  design  principles  and  specific 
design  considerations  for  Co-oP.  Chapter  III  presents 
individual  screen  designs  and  provides  an  in  depth  analysis  of 
screen  architecture,  including  limitations  and  benefits  of  GUI 


guidelines  in  conveying  current  Co-oP  model  requirements. 
Chapter  IV  provides  a  summary  of  findings  and  guidance  for 
future  considerations. 


II.  INTERFACE  DESIGN  PRINCIPLES 

A.   GRAPHICAL  USER  INTERFACES 

Current  trends  in  software  applications  are  increasingly- 
taking  into  account  how  the  user  will  interact  with  the 
computer.   According  to  Hooper  [Ref.  2: p. 9], 

"In  research  on  interface  design  we  frequently  allude 
to  the  creation  of  environments  for  enhanced 
interaction  and  problem  solving." 

Designers  are  now  recognizing  that  along  with  new  advances  in 

hardware  technology  and  expanded  computing  capabilities,  that 

ultimately   end   user   use   determines   how   successful   an 

application  actually  is.   Hooper  adds  [Ref.  2:p.9], 

"Similarly  we  often  distinguish  the  aesthetics  of  an 
interface  from  its  functionality,  and  we  emphasize  the 
importance  of  the  satisfaction  of  a  human  user  as  a 
criterion  for  evaluation  rather  than  the  objective 
analysis  of  the  technological  power  of  a  particular 
system. " 

In  responding  to  human  user  satisfaction  as  a  criterion  for 

evaluation,   and   thus   considered   as   part   of   design 

considerations,   graphical   interfaces   are   becoming   the 

designers  interface  of  choice.   Popularized  in  1984  by  the 

Apple  Macintosh,  this  type  of  interface  has  come  to  be  known 

as  Graphical  User  Interface  (GUI)  [Ref.  3:p.250]. 


1.  Design  Principles  of  Graphical  User  Interfaces 

Conveying  information  about  data  and  functions  visually 

allows  designers  the  ability  to  accurately  model  applications. 

According  to  Gaines  and  Shaw  [Ref.  4:p.80], 

"Users  will  model  the  computer  system  and  form  new 

expectations  based  on  their  interaction  with  it.  The 

system  should  be  designed  to  induce  accurate  models  and 
correct  expectations." 

In  order  for  a  user  to  fully  benefit  from  an  application,  he 

must  first  be  able  to  interact  with  it.   This  interaction 

begins  at  the  interface  both  in  its  controls  and  the  way 

information  is  displayed.   In  modeling  the  application,  the 

interface  must  be  easy  to  understand.    If  the  user  has 

difficulties  with  understanding  the  application  as  a  result  of 

a  complicated  or  incomplete  computer  interface,  his  attention 

is  diverted  from  the  application  and  his  understanding  of  the 

problem  or  overall  work  effectiveness  suffers.   A  properly 

designed  graphical  user  interface  parallels  the  application 

model  both  through  control  and  data  exchange.  This  alleviates 

user  communication  anxiety  and  allows  him  to  concentrate  on 

the  task  at  hand. 

2 .  GUI  Components 

There  are  currently  several  organizations  marketing 
graphical  interfaces  that  share  some  but  not  all  common 
features.  Table  1  lists  some  of  the  larger  GUI  products  along 
with  their  associated  organizations.  The  following  is  a  list 
of  parts  typically  associated  with  a  GUI  [Ref.  3:p.  250]; 


a  pointing  device,  typically  a  mouse 

on-screen  menus  that  can  appear  or  disappear  under 
pointing-device  control 

windows  that  graphically  display  what  the  computer  is 
doing 

icons  that  represent  files,  directories,  and  so  on 

dialogue  boxes,  buttons,  sliders,  check  boxes,  and  a 
plethora  of  other  graphical  widgets  that  let  you  tell  the 
computer  what  to  do  and  how  to  do  it 


Table  1 


CURRENT  GRAPHICAL  USER  INTERFACES 


Organizations 

Product 

Apple 

Macintosh 

Microsoft 

Windows 

IBM  with  Microsoft 

OS/2  Presentation 

Diqital  Ecruipment  Corp. 

DECwindows 

Open  Software  Foundation 

Motif 

Santa  Cruz  Operation  (SCO) 

Open  Desktop 

Commodore  Amiqa 

Intuition 

NeXT  Computer 

NeXTStep 

Diqital  Research 

GEM 

Sun  Microsystems 

Open  Look 

Hewlett-Packard  with  Microsoft 

Common  X  Interface 

Hewlett  -  Packard 

NewWave 

Source:  [Ref.  3] 


Additionally  the  following  is  a  list  of  some  common  GUI 

controls : 

•  Command  button:  Performs  a  task  when  chosen  by  the  user. 
Some  examples  are  the  "OK"  button,  the  "Cancel"  button, 
and  the  "Enter"  button. 


•  Check  box:  Displays  an  option  that  can  be  turned  on  or 
off.  Check  boxes  may  be  used  in  groups  to  display 
multiple  options. 

•  Option  button:  Sometimes  referred  to  as  the  "radio 
button"  displays  an  option  that  can  be  turned  on  or  off. 

•  Combo  box:  This  control  allows  the  user  to  make  a 
selection  by  typing  text  or  selecting  an  item  from  the 
list  below  it. 

•  List  box:  Displays  a  list  from  which  the  user  can  choose 
one. 

•  Text  box:  Can  either  display  information  that  is 
specified  or  that  the  user  enters. 

•  Action  bar:  Also  known  as  the  Action  Menu  provides  a 
means  of  displaying  selectable  drop  down  menu  boxes. 


Not  all  GUIs  have  all  these  features.    Some  may  not 

accommodate  a  pointing  device  or  lack  visual  features  such  as 

icons  or  other  specific  graphical  devices.   Hayes  and  Baran 

have  identified  three  similarities  [Ref.  3:p.  250], 

"...most  GUIs  consist  of  three  major  components:  a 
windowing  system,  an  imaging  model,  and  a  application 
program  interface  (API)." 

The  windowing  system  is  described  as  a  set  of  programming 

tools  and  commands  that  are  used  to  build  interface  windows 

and  include  the  menus,  controls,  dialogue  boxes,  and  commands 

that  make  up  the  interface.   The  imaging  model  defines  the 

creation  of  fonts  and  graphics.  Two  examples  are  Macintosh's 

Quickdraw  and  Microsoft's  Graphic  Programming  Interface  for 

OS/2 .   The  API  is  a  set  of  programming  function  calls  and  is 

how  the  programmer  specifies  what  graphics  will  appear  on  the 

screen. 
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While  Hayes  and  Baran  have  defined  a  GUI  in  terms  of  three 
components,  Myers  identifies  the  user  interface  as  a  logical 
part  of  the  window  manager  [Ref .  5:p.  67] .  He  identifies  a 
base  layer  that  implements  the  functionality  of  the  windows 
manager.  It  consists  of  two  parts,  one  to  handle  the  display 
of  graphics  and  a  second  part  to  access  input  devices.  Termed 
the  program  interface  or  application,  it  has  a  primary  purpose 
of  interfacing  with  other  programs.  The  second  layer  is  the 
user  interface.  This  is  the  visible  layer  and  is  further 
broken  down  into  two  parts.  The  layer  associated  with 
pictures  or  displays  is  termed  presentation,  and  the  layer 
which  allows  the  user  commands  to  manipulate  controls  is 
termed  operations. 

In  the  development  of  Co-oP's  prototype  GUI,  the 
representation  of  the  underlying  application  is  emphasized. 
According  to  IBM's  Advanced  Interface  Design  Guide,  the 
designer  of  an  interface  provides  the  screen  components  which 
best  support  that  application  [Ref.  6:p.3].  In  following 
current  trends  in  emphasizing  the  visual  interface  as  a  means 
of  encouraging  user  understanding  and  participation,  this 
prototype  GUI,  being  developed  in  Visual  Basic,  emphasizes  the 
user's  perspective  in  presenting  an  application. 

B.   GENERAL  DESIGN  PRINCIPLES 

Design  guidelines  for  GUIs  are  not  revolutionary  but 
continuations  of  established  principles.  An  interface  should 
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present  a  clear,  organized  representation  of  the  application 
it  is  conveying.  Shneiderman  identifies  8  underlying 
principles  of  design  [Ref.  7: pp.  60-62]; 

•  Strive  for  consistency 

•  Enable  frequent  users  to  use  shortcuts 

•  Offer  informative  feedback 

•  Design  dialogues  to  yield  closure 

•  Offer  simple  error  handling 

•  Permit  easy  reversal  of  actions 

•  Support  internal  locus  of  control 

•  Reduce  short-term  memory  load 

Consistency  in  an  application  includes  controls,  commands, 
actions,  terminology,  menus,  and  screen  layout.  By  enforcing 
consistency,  the  designer  is  able  to  reinforce  an  application, 
allowing  the  user  to  concentrate  on  the  problem  as  his 
interaction  through  the  interface  become  secondary.  The  use 
of  special  keys  and  commands  allow  the  knowledgeable  users  to 
reduce  the  number  of  interactions  through  shortcuts. 
Windowing  interfaces  can  be  easily  manipulated  by  the 
experienced  user  to  quickly  navigate  through  an  application. 
Visual  feedback  allows  users  to  see  consequence  of  actions, 
whether  it  be  an  error  message  or  subtle  change  of  color. 
Providing  a  sense  of  closure  allow  the  user  a  feeling  of 
accomplishment  and  termination  to  the  current  action  and 
enables  him  to  move  on  to  the  next  action.  Error  handling 
should  be  simple.    Provide  detection  mechanisms  and  easy 
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correction  capability.    The  user  should  not  worry  that 

improper  commands  or  input  would  adversely  effect  data.   Easy 

reversal  of  actions  allow  the  user  to  explore  the  system  free 

from  the  anxiety  of  making  mistakes  that  cannot  be  easily 

corrected  or  have  adverse  effect  on  the  application.   Allow 

the  user  to  be  in  control.   His  actions  should  be  by  choice 

rather  than  responding  to  rigid  sequential  input.   Reduce 

memory  effort  of  the  user  by  simplifying  screens  and  sequence 

of  actions.   User  actions  should  be  obvious  with  appropriate 

help  mechanisms  to  alleviate  the  amount  of  information  the 

user  must  work  with.   These  principles  of  dialogue  design 

readily  equate  to  the  design  of  visual  interfaces.    The 

designer  strives  for  an  interface  that  is  easy  to  control, 

simple  to  understand  and  will  reinforce  the  users  expectations 

of  the  application. 

The  enhancement  of  the  user  interface  must  convey  an  image 

of  the  application.   Merely  making  an  interface  graphically 

appealing  is  not  a  means  to  making  it  more  effective. 

Regarding  the  design  of  GUIs,  Marcus  notes  [Ref.  8:p.  107]; 

"Graphic  design  can  help  GUIs  achieve  their  potential  to 
communicate.  Information-oriented,  systematic  graphic 
design  is  the  use  of  typography,  symbols,  color,  and  other 
static  and  dynamic  graphics  to  convey  facts,  concepts,  and 
emotions . " 

He  further  identifies  three  principles  as  a  useful  guide  to 

research  and  development  [Ref.  8]  ; 

•  Organize:    Provide  the  user  with  a  clear  consistent 
conceptual   structure.     This   includes   concepts   of 
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consistency  both  in  screen  design  and  controls,   and 
navigability  through  the  application. 

•  Economize:  Maximize  the  effectiveness  of  a  minimal  set  of 
cues.  Limit  the  number  of  controls  to  what  is  absolutely 
required  and  avoid  unnecessary  items. 

•  Communicate:  Match  the  presentation  to  the  capabilities 
of  the  user.  Communicate  through  visualization  by 
balancing  aspects  of  color,  text,  and  symbols  in 
representing  the  application. 


1.   User  Control 

In  designing  the  visual  interface,  mechanisms  of  control 

should  be  balanced  to  accommodate  both  the  experienced  user 

and  novice.   Shneiderman  writes  [Ref.  9:p.  226]; 

"A  driving  force  in  human  behavior  is  the  desire  to 
control.  Some  individuals  have  powerful  needs  to  attain 
and  maintain  control  of  their  total  environment;  others 
are  less  strongly  motivated  in  this  direction  and  are  more 
accepting  of  their  fate." 

In  accommodating  the  users  perspective,  three  issues  should  be 

addressed.   They  include  the  number  of  controls,  escape,  and 

navigation.    In  addition,  and  of  major  concern  from  most 

authors  is  the  concept  of  consistency,  Marcus  relates  it  to 

both  consistency  in  conventions  and  rules  [Ref.  8] .   In  terms 

of  control,  make  commands  familiar  with  similar  consequence  of 

action   and   reinforce   consistency   across   the   entire 

application. 

a.  Number  of  commands 

Two  factors  are  reinforced  in  terms  of  commands.   Marcus 

writes,   "Simplicity  suggests  that  we  include  only  those 
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elements  that  are  essential  for  communication."  [Ref.  10:p. 
121]  .  Myers  notes  that  a  large  number  of  commands  allow  users 
to  perform  functions  many  ways  but  it  may  add  difficulty  in 
knowing  which  command  to  use  [Ref.  5:p.78].  Simply  put, 
minimize  the  number  of  commands  and  make  them  clear  as  to 
function. 

b.  Escape 

Another  control  aspect  is  the  users  ability  to  escape  a 
command  or  action.  Shneiderman  discusses  user  anxiety  in 
terms  of  user  ability  in  using  computer  systems  and  their  fear 
of  altering  data  [Ref.  9:p.  225-226].  When  interacting  with 
an  application  a  user,  in  order  to  be  in  control,  should  be 
able  to  exit  or  escape  a  function  without  fear  of  altering 
data.  This  capability  allows  him  to  explore  system  actions 
and  capabilities  without  fear  of  data  corruption.  As  stated 
by  Gaines  and  Shaw,  "There  should  be  a  facility  to  enable  the 
user  to  escape  at  will  leaving  the  state  of  the  system  well 
defined."  [Ref.  4:p.  81]. 

c .  Naviga ti on 

The  user  must  be  able  to  develop  a  sense  of  control  over 
his  actions,  which  includes  both  the  concept  of  escape  as 
previously  described  but  also  a  sense  of  controlling 
subsequent  actions.  If  the  user  for  any  reason  needs  to 
terminate  an  action  or  return  to  a  previous  application 
module,  he  should  be  provided  that  mechanism.  Being  caught  in 
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a  loop  requiring  user  input  before  termination  removes  that 
sense  of  control.  The  application  should  avoid  traditional 
modes  of  sequential  input  that  restrict  user  interaction  to  a 
rigidly  prescribed  routing  and  allow  the  user  to  control  or 
navigate  through  the  application  as  it  best  meets  his  needs. 

2 .   Screen  Design 

The  importance  of  the  user  interface  relates  directly  to 
what  the  user  sees.  A  effective  screen  design  assists  rather 
than  hinders  the  users  understanding  of  the  application.  The 
use  of  graphical  displays  enhance  user  visualization.  The 
designer  must  also  curtail  graphics  as  if  they  are  overdone, 
they  can  overpower  the  user  and  complicate  his  problem 
understanding.  According  to  Marcus,  "You  must  select 
visualization  techniques  that  are  appropriate  to  the  output 
display  technology."  [Ref.  10:p.  122].  He  further  identifies 
aspects  of  legibility,  readability,  typography,  symbolism, 
view,  and  color.  Three  areas  pertaining  to  a  graphical 
interface  need  attention,  color,  screen  layout,  and 
typography.  As  in  user  controls,  consistency  is  required 
across  screen  design.  IBMs  Advanced  Interface  Design  Guide 
notes  that  users  become  familiar  with  interface  components 
when  the  visual  appearance  of  these  components  are  consistent 
across  applications  [Ref.  6:p.  11]. 
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a.  Color 

Marcus  notes  the  use  of  color  in  graphical  interfaces 
greatly  enhances  problem  presentation  if  used  correctly  [Ref . 
ll:p.  135].  He  adds,  "Conversely,  the  inappropriate  use  of 
color  can  seriously  reduce  the  functionality  of  a  display 
system.".  Marcus  identifies  three  principles  of  color  design: 
color  organization,  color  economy,  and  color  communication. 
Consistency,  as  inmost  designs,  guides  organization.  The  use 
of  similar  colored  backgrounds,  controls,  and  cues  allow  the 
user  to  associate  common  displays.  In  presenting  screens  to 
users,  avoid  overly  dazzling,  multicolored  displays .  Restrict 
the  number  of  colors  to  5±2  for  simplicity  [Ref.  11 :p.  137] . 
Allow  colors  to  communicate.  Subtle  color  change  add  accents 
and  separate  areas  of  display.  Contrasting  colors  are 
attention  getters  and  could  be  used  to  draw  focus  for  emphasis 
or  warning.  Shneiderman  points  out  several  guidelines  for 
designers  in  relation  to  color  use  [Ref.  7:pp.  337-342]: 

•  Use  color  conservatively 

•  Limit  the  number  of  colors 

•  Recognize  the  power  of  color  as  a  coding  technique 

•  Color  coding  should  support  the  task 

•  Color  coding  should  appear  with  minimal  user  effort 

•  Color  coding  is  under  user  control 

•  Design  for  monochrome  first 

•  Color  can  help  in  formatting 

•  Be  consistent  in  color  coding 
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•  Be  alert  to  common  expectations  about  color  codes 

•  Use  color  changes  to  indicate  status  changes 

•  Use  color  in  graphic  display  for  greater  information 
density 

•  Beware  of  the  loss  of  resolution  with  color  displays 
The  bottom  line  in  adding  color  to  screen  design  is  to  use  it 
to  augment  or  highlight  information,  not  over  power  the  user 
with  excess. 

b.  Screen  Layout 
Design  considerations  relating  to  screen  layout  include 
consistency,  format,  and  user  memory.  As  previously  noted, 
consistency  across  screen  designs  needs  to  include  layout. 
Common  positioning  of  controls,  text,  menus,  and  forms  all 
lead  to  ease  of  comprehension  for  the  user.  By  enforcing 
consistency,  the  user,  in  becoming  familiar  with  format, 
spends  less  time  with  the  physical  display  and  more  time 
concentrating  on  the  actual  application.  Designing  format 
that  is  natural  to  what  the  user  expects  contributes  to  his 
ease  of  interaction.  Neat  forms,  proper  alignment,  and  simple 
labeling  that  reflect  the  problem  all  lead  to  ease  of  use. 
Avoid  over  powering  the  user  with  excessive  clutter. 
Regarding  screen  layouts,  Marcus  advises  the  use  of  a  grid 
structure,  standard  screen  layouts,  a  group- related  elements 
[Ref .  8]  .  Provide  only  the  controls  and  displays  that  are 
needed  by  the  applications  current  data  exchange  requirements. 
The  way  the  screen  is  spatially  organized  as  in  color,  can 
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help  or  hinder  the  user  interaction.  The  use  of  menus, 
controls,  and  dialogue  should  be  limited  to  current 
application  requirements. 
c.  Typography 
Typography  consists  of  the  typefaces  and  groupings  of  text 
in  screen  design.  Marcus  notes  that  one  of  the  key  elements 
to  legibility  and  readability  is  the  use  of  typography  in 
design  of  the  user  interface  [Ref.  10:p.  123].  He  further 
suggests  to  limiting  typefaces  to  a  maximum  of  three.  The 
typeface  chosen  should  be  legible  and  distinctive  and  not  be 
hidden  in  background  clutter. 

C.   GUI  DESIGN  CONSIDERATIONS  FOR  COOP 

Interpretation  of  the  Co-oP  model  is  in  large  part  based 
on  the  current  version's  interface.  Utilizing  traditional 
menu  format  combined  with  sequential  queries,  it  is  rigidly 
structured.  The  interface  itself  is  divided  into  four 
windows,  the  Step  window,  the  Dialogue  window,  the  Working 
window,  and  the  Solution  window  [Ref.  l:pp.  141-143].  See 
Figure  1 . 
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Figure  1.   Original  Four  Window  Design 

Source:  [Ref.  l:p.  143] 

A  primary  concern  in  re-designing  this  interface  is  the 
incorporation  of  mechanisms  allowing  user  control  and 
establishing  visual  feedback  specific  to  inputs  requested  by 
the  user.  Also  mechanisms  designed  to  alert  the  user  to 
errors,  and  provide  adequate  help  dialogues  to  assist  him  in 
utilizing  the  model  through  the  interface. 

1.   Interpreting  the  Model 

In  interpreting  the  model,  preservation  of  the  multiple 
criteria  decision  method  and  other  decision  tools  was 
paramount.  Following  the  original  interface,  an  appropriate 
way  to  insure  required  information  flow  is  to  follow  a 
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multiple  criteria  problem  solving  process  [Ref.  l:p.  120]. 
This  process  consists  of: 

(i)  Group  Problem  Definition 

(ii)  Group  Norm  Definition 

(iii)  Individual  Prioritization  of  Evaluation  Criteria 

(iv)  Individual  Evaluation  and  Selection  of  Alternatives 

(v)  Direct  Evaluation  of  Alternatives 

(vi)   Group  Selection  of  Alternatives  using  techniques  of 
aggregation  of  preferences 

(vii)  Consensus  seeking  and  negotiation  analysis 

Note  that  step  (v)  may  be  substituted  for  steps  (iii)  and 
(iv)  .  This  general  format  remains  unchanged.  The  first  step 
is  collectively  identifying  and  defining  the  problem  and 
secondly  identifying  the  group  members  and  determining 
communication  restrictions.  The  third  step  allows  two  methods 
of  prioritizing  evaluation  criteria.  The  user  chooses  either 
the  AHP  or  direct  method  of  ranking.  Step  (iv)  ,  evaluation  of 
alternatives  offers  the  AHP  method,  ELECTRE,  and  direct 
ranking  to  rate  alternatives.  As  pointed  out,  step  (v)  may  be 
substituted  for  both  previous  steps.  Using  four  aggregation 
preferences,  step  (vi)  computes  group  results.  Finally,  step 
(vi)  permits  a  consensus  seeking  algorithm  if  a  unanimous 
decision  is  not  obtained. 
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2.  Channeling  Input 

In  determining  Interface  design,  input  choices  require 
careful  thought.  With  numerous  input  devices  such  as  simple 
text  boxes,  drop-down  list  boxes,  or  scrolling  methods,  to 
mention  just  a  few,  the  method  chosen  is  needed  to  reflect  as 
much  as  possible  what  the  user's  mental  image  of  Co-oP  model 
dictated.  Persistent  to  allowing  the  user  to  be  in  control, 
input  mechanisms  need  to  be  broken  down  into  steps  easily 
understood  and  concentrated  on  and  allowing  a  means  of  escape 
when  completed  [Ref .  9:p.  225]  .  This  allows  the  user  to  break 
down  input  mechanisms  into  smaller,  easily  managed  portions. 

3.  Limiting  Output 

In  designing  for  output,  a  major  consideration  was 
limiting  information  presented  to  the  user.  The  combination 
of  tables,  matrixes,  and  graphs,  as  presented  in  the  original 
interface  tend  to  overpower  the  interface  display  and  present 
a  cluttered  appearance.  Limiting  output  to  user  requests 
again  allow  him  to  control  presentations,  and  allow  him  to 
determine  output  requirements  that  meet  his  needs.  In 
striving  to  meet  this  criteria,  multiple,  overlapping  windows 
that  are  easily  selected  by  the  user  enable  customization  of 
output  that  best  serve  his  requirements. 

4 .  Networking  Issues 

Design  of  a  DSS  to  support  multiple  decision  making  should 
also  consider  the  developing  technologies  of  computer  networks 
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and  electronic  communication  [Ref.  l:p.  35].  Characteristics 
of  distributed  systems  allow  individual  users  the  ability  to 
process  applications  of  a  group  decision  support  system  that 
is  independent  of  network  technology.  Bui  identifies  six 
possible  types  of  DSS  user  interactions  [Ref.  l:pp.  39-42]: 

•  Type  1:  The  traditional  DSS  paradigm  with  the  user 
interacting  directly  with  an  individual  DSS  with  no 
communications  support. 

•  Type  2:  A  group  of  users  interacting  with  a  DSS,  usually 
with  an  intermediary. 

•  Type  3:  Essentially  a  combination  of  the  previous  two  in 
which  each  user  interacts  directly  with  an  individual  DSS 
with  the  addition  of  some  type  of  electronic  aggregation 
of  preferences. 

•  Type  4 :  This  DSS  framework  addresses  the  sharing  of  a 
GDSS  but  is  loosely  coupled  and  individuals  lack  knowledge 
about  other  group  members . 

•  Type  5 :  This  GDSS  supports  both  individual  DSS  and  group 
DSS  as  it  provides  a  multilateral  network  relationship  of 
shared  DSS. 

•  Type  6:  This  GDSS,  as  in  the  previous  type  represent  a 
distributed  problem  solving  system  with  individual  members 
interacting  with  the  system.  Additionally  Type  6  provides 
for  a  mediator. 

A  networked  GDSS  can  provide  four  main  functions  [Ref.  l:p. 

45]  : 


(i)     monitoring  of  data  exchange 

(ii)    automatic  selection  of  appropriate  group  decision 
techniques 

(iii)   computation  and  explanation  of  a  group  decision 

(iv)    suggestion  for  a  discussion  of  individual  differences 
or  for  a  redefinition  of  the  problem  if  attempts  to 
reach  consensus  fail 
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The  provision  of  networking  in  a  GDSS  allows  for 
geographical  dispersion  of  individual  members.  Communication 
can  be  either  on-line  or  sequential,  thus  removing 
requirements  for  set  times  of  participation  and  allowing  each 
member  the  ability  to  interact  at  his  convenience. 
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III.  INDIVIDUAL  SCREEN  DESIGNS 

A.   MAIN  CO-OP  SCREEN 

This  initial  screen  design  titled,  Cooperative  Multiple 
Criteria  Group  Decision  Maker,  is  the  user  interface  to  the 
Co-oP  model  (see  Figure  2)  .  Each  labeled  Command  Button 
identifies  one  of  the  models  seven  problem  steps  and  when 
clicked,  opens  that  particular  sub-module.  The  design  itself 
represents  a  flow  chart  of  how  the  problem  is  to  proceed.  The 
first  two  steps  of  a  problem  are  the  definition  of  problem 
alternatives  along  with  criteria  for  measurement,  and  defining 
the  group  norm  which  includes  identifying  members  and 
communication  parameters.  These  first  two  steps  must  be 
completed  before  continuing  the  problem.  The  model  then 
allows  two  courses  of  action,  the  first  is  to  utilize  the 
various  model  components  to  prioritize  criteria  and  evaluate 
alternatives.  An  alternate  second  method,  if  chosen,  allows 
the  user  to  rank  alternatives  directly  without  going  through 
formal  alternative  evaluations.  Both  These  two  methods  lead 
into  the  group  decision  button  which  opens  that  module  and  the 
identifying  of  negotiable  alternatives.  The  final  command 
button  exits  the  program.  Command  Buttons  were  chosen  as  a 
graphical  representation  of  the  flow  of  the  Co-oP  model  over 
traditional  menu  driven  selections.   By  presenting  an  overall 
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Figure  2.   Co-oP  Main  Screen 
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visual  display  of  the  application  model  steps,  the  user  should 
gain  an  immediate  understanding  of  model  requirements  and  a 
sense  of  control  over  his  actions.  Additionally,  two  menu 
items  are  available  from  the  Action  Bar.  The  File  menu 
provides  choices  relating  to  document  saving  by  access  to  a 
dialogue  box  and  an  additional  exit  selection.  The  Help  menu 
provides  choices  of  a  general  help  screen  and  data  about  the 
interface. 

B.   GROUP  PROBLEM  DEFINITION  MODULE 

This  module  correlates  to  step  (i)  of  the  Co-oP 
application  (see  page  20)  .  The  current  prototype  module 
contains  five  main  screens.  Three  screens  are  dialogue  boxes 
with  minimal  information  requested  from  the  user.  The 
remaining  two  screens  requiring  the  user  to  define  both 
problem  Alternatives  and  Evaluation  Criteria,  involve  text 
input.  In  addition  there  are  various  additional  Help, 
Password,  and  Dialogue  boxes  that  will  be  covered  in 
miscellaneous  screen  designs. 

1.   Problem  Identification  Screen 

This  simple  dialogue  box  allows  the  user  to  select  via 
radio  buttons  whether  he  desires  to  define  a  new  Group  Problem 
or  open  a  previously  defined  Group  Problem  (see  Figure  3)  . 
The  OK  button  accepts  whatever  choice  he  makes  and  the  Cancel 
Button  returns  the  user  to  the  Main  screen  without  accepting 
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any  user  input.   The  default  selection  is  to  define  a  new 
Group  Problem. 

2.  Problem  Files  Screen 

This  interface  allows  the  user  to  select  a  previously 
defined  problem  file  for  use  in  his  current  application 
session  (see  Figure  4) .  It  contains  visual  fields  indicating 
current  drive,  directory,  and  associated  problem  files  that 
are  restricted  to  files  with  a  .def  extension.  All  data 
relating  to  the  problem  definition  will  be  maintained  in  this 
file.  In  addition  current  path  is  displayed  in  a  text  box  for 
the  users  reference.  The  user  has  a  choice  of  three  Command 
buttons.  The  OK  command  button  selects  user  file  selection. 
The  Cancel  button  accepts  no  file  and  returns  the  user  to  the 
Problem  Identification  screen.  And  finally  the  Help  button, 
which  is  intended  to  access  an  informative  screen  guidelines 
dialogue  box. 

3.  Problem  Definition  Screen 

This  screen  interface  allows  the  user  to  select  either 
Identification  of  Alternatives  or  the  Evaluation  Criteria 
Hierarchy  selection  via  radio  buttons  (see  Figure  5) .  This 
dialogue  box  allows  the  user  to  enter  the  Problem  Name  if  a 
new  problem  is  to  be  defined  or  display  the  problem  name  if  a 
previous  problem  was  selected  via  a  text  box.  The  OK  button 
accepts  user  choice  with  the  Identification  of  Alternatives  as 
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Figure  3.   Problem  Identification  Screen 
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Figure  4.   Problem  Files  Screen 
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the  default  value  and  the  Cancel  button  returns  the  user  to 
the  Problem  Identification  screen.  Additionally,  this  screen 
has  File  and  Help  menus  accessed  through  an  action  bar.  These 
additional  dialogue  box  functions  will  be  discussed  in  general 
in  miscellaneous  screen  designs. 

4.   Identification  of  Alternatives 

This  screen  allows  the  user  to  input  up  to  15  alternatives 
for  the  group  to  evaluate  (see  Figure  6) .  In  determining  the 
number  of  alternatives,  screen  limitations  in  the  design 
software  aesthetically  limited  this  prototype  to  15  choices. 
Ideally  the  number  of  alternatives  should  allow  up  to  40 
choices.  The  Group  Problem  Name  is  automatically  displayed 
for  reference  at  the  top  of  the  display  in  a  text  box.  The 
screen  is  formatted  for  up  to  15  choices,  of  which  only  two 
are  initially  displayed,  the  rest  being  hidden  until  the  user 
selects  additional  alternatives  to  enter  via  an  Add 
Alternative  Command  button.  Conversely,  if  the  user  wishes  to 
eliminate  alternatives  he  can  use  a  Delete  Alternative  button 
to  remove  in  reverse  order,  his  number  of  choices.  The  Enter 
button  accepts  user  input  while  the  Cancel  button  returns  the 
user  to  the  Problem  Definition  screen  display.  This  screen 
also  introduces  a  Help  button  with  the  ■?■  caption.  By 
utilizing  a  Command  button  for  additional  help  screen  access, 
it  is  graphically  incorporated  into  the  screen  format  vice 
having  a  single  Help  menu  option  on  an  action  bar. 
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Figure  5.   Problem  Definition  Screen 
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Figure  6.   Identification  of  Alternatives  Screen 
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5.   Hierarchy  of  Evaluation  Criteria  Screen 

This  screen  interface  allows  the  user  to  input  via  text 
boxes  a  hierarchy  of  evaluation  criteria  (see  Figure  7)  . 
There  are  three  levels  of  hierarchy  with  up  to  ten  choices 
available  at  each  level.  The  default  display  is  the  first 
level  indicated  by  the  three  Radio  buttons  in  the  Select  Level 
frame  box.  Additionally,  if  further  levels  of  detail  are 
required  for  criteria  evaluation,  the  user  can  select  a  second 
or  third  level  which  is  based  on  the  previous  levels  selection 
number.  An  additional  dialogue  box  corresponding  to  that 
level  will  overlay  the  current  window  and  allow  for  similar 
format  of  data  entry  allowing  further  amplification  of  user 
input  relating  to  current  level  selected.  The  default 
selection  is  to  define  a  new  Group  Problem.  The  Group  Problem 
Name  is  displayed  for  user  reference  in  a  text  box  near  the 
top  of  the  screen.  The  enter  button  accepts  inputs  and  the 
Cancel  button  returns  the  user  to  the  Problem  Definition 
Screen.  As  in  the  previous  screen  design,  Add  Criteria  and 
Delete  Criteria  allow  the  user  to  modify  the  number  of 
criteria  for  input. 

C.   GROUP  NORM  DEFINITION  MODULE 

This  module  corresponds  to  step  (ii)  of  the  Co-oP 
application  (see  page  20) .  This  current  prototype  module 
contains  ten  primary  screen  interfaces.  Four  of  the  screen 
designs  are  dialogue  boxes  with  minimal  input  required  from 
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Figure  7.   Hierarchy  of  Evaluation  Criteria  Screen 
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the  user.  Two  screens  require  text  input  that  use  an  updated 
f ill-in-the-blank  format.  The  remaining  four  screens  utilize 
either  radio  button  or  check  box  functions  for  user  input. 
Screen  formats  were  designed  to  focus  the  user  on  current  data 
exchange  requirements  without  excessive  screen  clutter. 

1.  Group  Norm  Identification  Screen 

This  screen  interface  is  similar  in  design  to  the  Problem 
Identification  screen  on  page  26,  (see  Figure  8)  .  The  user  is 
given  a  choice  of  defining  a  new  group  norm  or  selecting  a 
previous  definition  via  radio  button  selection.  The  OK  button 
accepts  user  input  and  the  Cancel  button  returns  the  user  to 
the  Main  Co-oP  screen.  The  definition  of  a  new  group  is  the 
default . 

2.  Group  Norm  Files  Screen 

The  user  is  allowed  to  retrieve  a  previously  defined  group 
norm  for  the  current  session  (see  Figure  9) .  Utilizing  the 
same  layout  as  the  Problem  Definition  Screen  (see  page  27)  ,  it 
has  visual  references  to  the  drive,  directory,  and 
corresponding  files  with  a  .GN  extension.  All  data  pertaining 
to  the  Group  Norm  parameters  will  be  maintained  in  this  file. 
Additionally,  the  current  path  is  displayed  for  user 
reference.  The  command  button  OK  accepts  the  highlighted 
group  norm  file  for  manipulation.  The  Cancel  button  returns 
the  user  to  the  Group  Norm  Identification  Screen  without 
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Figure  9.   Group  Norm  Files  Screen 
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accepting  any  input.   The  Help  button  "?"  will  provide  access 
to  help  documentation. 

3.  Group  Norm  Definition  Screen 

This  interface  functions  much  the  same  way  as  the  Problem 
Definition  Screen  (see  page  27)  .  Through  radio  button 
selection,  the  user  is  able  to  select  either  Identification  of 
Group  Members,  Group  Decision  Techniques,  or  Information 
Exchange  (see  Figure  10) .  If  not  a  previously  defined  group 
norm,  the  user  enters  a  group  norm  name  in  the  text  box 
provided.  The  Enter  button  accepts  the  users  radio  button 
selection  and  displays  that  corresponding  screen  interface. 
The  Cancel  button  returns  without  accepting  any  data  to  the 
Group  Norm  Identification  Screen.  When  the  user  completes 
selection  and  data  input  of  all  three  radio  button  options,  a 
dialogue  will  prompt  him  to  save  that  data.  Two  additional 
controls,  a  File  menu  selection  and  a  Help  menu  selection  are 
located  on  an  action  bar  at  the  top  of  the  screen. 

4.  Identification  of  Group  Members  Screen 

This  dialogue  box  is  displayed  when  the  user  selects  the 
first  radio  button  on  the  Group  Norm  definition  screen.  It 
consists  of  three  text  boxes  (see  Figure  11) .  The  first  text 
box  allows  the  user  to  identify  the  Group  Norm  builder.  The 
second  input  is  a  five  character  group  password.  The  last 
input  is  the  number  of  decision  makers  in  the  group.   The 
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Figure  10.      Group  Norm  Definition  Screen 
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Figure  11.   Identification  of  Group  Members  Screen 
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Enter  button  accepts  data  input  and  the  Cancel  button  returns 
the  user  to  the  Group  Norm  Identification  screen. 

5.  Decision  Makers  Screen 

This  screen  interface  consists  of  simple  text  input  into 
appropriate  text  boxes  (see  Figure  12)  .  Up  to  15  group 
members  are  allowed.  Although  15  members  are  available,  only 
the  appropriate  number  of  text  boxes  required  are  visible  as 
indicated  by  the  third  input  on  the  previous  screen,  the 
remaining  unused  text  boxes  remain  invisible.  Selection  of 
the  Enter  command  button  accepts  the  group  list  and  the  Cancel 
button  returns  the  user  to  the  Identification  of  Group  Members 
screen. 

6 .  Group  Decision  Techniques  Screen 

Through  this  screen  interface,  the  user  defines  the 
framework  for  the  group  decision  techniques  (see  Figure  13). 
Specific  areas  covered  include: 

•  weighing  members  input 

•  restricting  the  members  input  based  on  his  area  of 
expertise 

•  members  decision  technique  to  be  used  in  group  decision 

•  selection  of  techniques  of  aggregation  of  preference 

•  computation  of  NAI 

The  interface  allows,  via  radio  button  selection,  the  members 
to  set  up  decision  techniques  before  continuing  with  an 
individual  session.  Radio  button  default  values  are  displayed 
in  individual  frame  boxes.   If,  as  a  result  of  button 
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Figure   12 .      Decision  Makers   Screen 
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selection,  further  amplification  is  required,  additional 
screens  will  overlay  the  current  screen  requesting  additional 
input.  The  Enter  button  accepts  the  data  input  and  the  Cancel 
button  returns  the  user  to  the  Group  Norm  definition  screen. 
Help  mechanisms  are  not  available  as  the  text  is  self 
explanatory. 

7 .  Individual  Decision  Weights  Screen 

This  screen  is  displayed  when  the  "No"  radio  button  is 
selected  for  weighted  majority  rule.  By  default,  each  group 
members  inputs  are  weighted  equally.  This  interface  allows 
the  group  members  (up  to  15)  to  be  assigned  different  decision 
input  weight.  The  actual  weights  can  be  either  input  directly 
by  the  group  or  manipulated  through  sliding  boxes  that 
incrementaly  increase  or  decrease  a  members  decision  weight 
factor  (see  Figure  14)  .  Selection  of  the  Enter  button  accepts 
input  and  the  Cancel  button  returns  the  user  to  the  Group 
Decision  Techniques  screen.  In  addition  a  Help  button  would 
allow  additional  amplification  of  how  to  input  and  manipulate 
the  sliding  boxes. 

8.  Individual  Criteria  Selection  Screen 

This  screen,  as  in  the  Individual  Decision  Weights  screen, 
appears  as  result  of  not  selecting  the  default  choice  in  the 
collective  evaluation  modes  frame  box.  The  default  value 
allows  each  member  to  evaluate  alternatives  based  on  all 
criteria.   Although  not  available  in  the  current  version  of 
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Figure  14.   Individual  Decision  Weights  Screen 
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Co-oP,  this  capability,  included  as  part  of  the  prototype 
interface  allows  the  group  to  selectively  choose  areas  of 
expertise  for  individual  members  to  evaluate  alternatives. 
The  screen  is  designed  to  allow  the  group  to  easily  select 
criteria  for  evaluation  for  each  individual  member  who  is 
identified  by  number  (see  Figure  15) .  Check  boxes  can  either 
represent  individual  areas  of  criteria  to  be  included  or  as 
areas  to  be  suspended  for  that  particular  member.  Only  the 
first  criterion  layer  is  to  be  available  for  selective  areas 
of  expertise.  Selection  of  the  Continue  button  accepts  agreed 
data  and  Cancel  returns  the  user  to  the  Group  Decision 
Techniques  screen.  The  addition  of  a  help  button  is  intended 
to  allow  for  the  addition  of  help  dialogue  in  explaining  input 
format . 

9 .   Techniques  of  Aggregation  Screen 

The  default  value  in  determining  techniques  of  aggregation 
of  preferences  are  to  utilize  all  four  methods  which  include: 

•  SUM- OF -RANKS 

•  SUM- OF -OUTRANKING -RELATIONS 

•  ADDITIVE  RANKING 

•  MULTIPLICATIVE  RANKING 

The  group  can  choose  to  individually  select  each  method 
through  the  Technique  of  Aggregation  Screen.  This  screen 
interface  allows  the  user  to  select,  via  radio  buttons  whether 
to  enable  techniques  of  aggregation  (see  Figure  16) .   The 
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Enter  button  accepts  user  input  and  the  Cancel  button  returns 
the  user  to  the  Group  Decision  Techniques  screen. 

10.  The  Information  Exchange  Screen 

This  final  screen  interface  is  displayed  when  the  user 
chooses  the  third  radio  button  in  the  Group  Norm  Definition 
screen.  It  allows  group  members  to  set  various  communication 
parameters  as  the  group  norm  is  defined.  Radio  buttons  allow 
either  positive  or  negative  answers  to  specific  questions  and 
two  text  boxes  allow  date  and  time  entry  with  the  format 
indicated  (see  Figure  17) .  The  enter  button  accepts  imputed 
data  and  the  Cancel  button  returns  the  user  to  the  Group  Norm 
Definition  screen. 

D.   CRITERIA  PRIORITIZATION  MODULE 

As  part  of  the  Co-oP  application,  each  group  member  is 
allowed  to  rank  the  problems  evaluation  criteria.  This  module 
allows  group  individuals  two  methods  in  accomplishing  that 
process.  The  group  user  may  choose  the  method  of  Pairwise 
Comparison,  otherwise  known  as  the  Analytic  Hierarchy  Process 
(AHP)  .  If  the  user  does  not  require  a  formal  decision  tool, 
he  may  alternately  choose  a  method  of  direct  entry  of 
priorities.  A  major  design  consideration  for  this  module 
interface  requires  focusing  screen  presentation  to  the  current 
input  task  at  hand.  This  consideration  is  essential  when 
utilizing  pairwise  comparison.  This  decision  support  tool 
allows  the  user  to  compare  and  evaluate  two  alternatives  at  a 
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Figure  17 .   Information  Exchange  Screen 
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time,  and  thus  the  user  should  not  be  distracted  by  other 
display  elements.  This  module  consists  of  five  simple  boxes, 
along  with  two  interactive  screen  interfaces.  Additional 
dialogue,  error,  and  help  screens  will  be  covered  later  in  a 
miscellaneous  screen  interface  section. 

1.  Prioritization  of  Evaluation  Criteria  Screen 
Similar  in  function  to  either  the  Group  Norm 
Identification  screen  (see  page  33)  and  the  Problem  Definition 
screen  (see  page  27)  ,  this  screen  interface  serves  as  the 
modules  initial  screen  (see  Figure  18) .  Two  separate  combo 
box  lists  allow  the  user  to  either  type  in  the  name  of  the 
problem  and  group  norm  or  enable  a  drop  down  list  of  available 
choices.  Both  of  these  require  selection  to  initiate  the 
session  and  identify  previously  defined  parameters  to  be 
utilized.  In  addition  the  user  is  asked  to  input  his  name. 
It  is  intended  upon  name  input,  that  a  password  dialogue  box 
overlay  current  screen  and  request  the  five  character  password 
which  will  be  verified  with  the  group  norm  selected.  The 
password  screen  will  be  discussed  in  miscellaneous  screen 
designs.  If  the  password  is  correct,  the  user  chooses  via 
radio  buttons,  the  method  of  ranking  criteria.  The  Continue 
button  accepts  user  choice  and  displays  additional  interfaces. 
The  Cancel  button  returns  the  user  to  the  Co-oP  Main  screen. 
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2.   Pairwise  Comparison  Screen 

This  screen  interface  is  the  input  mechanism  for  the  AHP 
process.  The  upper  left  portion  of  the  screen  represents  up 
to  a  ten  by  ten  positive  reciprocal  matrix  (Ref.  l:p.  131). 
The  user  is  queried  about  preference  of  criteria  and  requested 
to  make  a  decision  in  the  following  frame  box  (see  Figure  19) . 
The  default  value  of  "no  preference"  returns  a  unit  value  of 
1.0  to  the  corresponding  two  criterion  in  the  matrix.  If 
either  "Yes"  or  "No"  is  selected,  proper  sequence  is 
determined  and  displayed  (see  Figure  20) .  The  user  is  then 
asked  to  determine  his  magnitude  of  preference  either  through 
direct  entry  in  the  shown  text  box  or  manipulation  of  a 
sliding  bar.  This  process  continues  until  all  criteria  in 
each  level  are  evaluated  as  to  preference.  Once  completed  the 
Priority  Vector  is  determined  and  displayed  for  user  reference 
and  the  Modify,  Stats,  and  Graph  buttons  will  become 
available.  The  Modify  button  opens  an  interface  that  allows 
the  user  to  change  the  current  data.  The  Stats  button 
displays  a  simple  screen  displaying  matrix  evaluation  data. 
The  Graph  button  allows  the  user  to  view  graphically  via  a  bar 
graph  (not  currently  available)  the  same  information  as 
displayed  in  the  Priority  Vector.  The  Enter  button  accepts 
user  input.  The  Cancel  button  returns  the  user  to  the 
Prioritization  of  Evaluation  Criteria  screen.  The  Help  "?" 
button  when  incorporated  will  identify  and  clarify  the  various 
input  and  display  mechanisms . 
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Figure  19 .   Pairwise  Comparison  Screen 


50 


1 

2 

3 

4 

1 

|Cost 

1.00 

2 

Maintenance 

1.00 

3 

Document  ati 

1.00 

4 

Capability 

1.00 

WMa 


,w.w.w.v.w. 


'■•■■■  ■  ■ :'-  ■  ■  ■  ■'■  ■■■ 


Cancel 


How  many  times  is      Cost  mote  important  than      Capability  ? 

II I L_ 


? 


Select  a  value: 


0.00 


1.0 

no  preference 


5.0 
absolutely  more  important 


Figure  20.   Pairwise  Comparison  Screen 


51 


3.  Modification  Technique  Screen 

This  simple  dialogue  box  allows  the  user  to  select  via 
radio  buttons  a  method  of  modifying  the  pairwise 
comparisonmatrix.  The  two  choices  available,  again  made  via 
radio  button  selection,  are  to  modify  the  matrix  directly  or 
to  select  specific  criteria  to  update  (see  Figure  21) .  The 
Enter  button  accepts  user  input  while  the  Cancel  button 
returns  the  user  to  the  Pairwise  Comparison  screen. 

4.  Criteria  Modification  Screen 

This  simple  dialogue  box  is  made  available  if  the  user 
opts  to  select  criteria  to  update  on  the  Modification 
Technique  screen.  Two  combo  boxes  with  lists  of  available 
criteria  are  provided  for  user  selection  (see  Figure  22)  . 
When  the  user  selects  the  Enter  button  for  data  acceptance, 
these  two  criteria  are  displayed  on  the  bottom  of  the  Pairwise 
Comparison  screen  for  evaluation  in  the  same  manner  as 
originally  input.  The  Cancel  button  returns  the  user  to  the 
Modification  Technique  screen  without  accepting  any  user 
input . 

5.  Statistical  Evaluation  Screen 

This  screen,  used  for  display  of  information  only, 
provides  statistical  data  relating  to  the  pairwise  matrix.  In 
addition  it  informs  the  user  through  a  short  message  of  how 
consistent  the  matrix  inputs  were  (see  Figure  23) .  The  OK 
button  returns  the  user  to  the  Pairwise  Comparison  screen. 
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6.  Priority  Vector  Graph  Screen 

This  screen  is  intended  again  only  to  provide  informative 
data  in  the  form  of  a  bar  graph  to  the  user  and  is  not 
currently  available.  It  is  intended  to  be  the  same  data  as 
shown  under  the  Priority  Vector  in  the  Pairwise  Comparison 
screen  only  in  the  form  of  a  bar  graph  for  graphic 
interpretation  for  the  user  (see  Figure  24)  .  Criteria  are 
displayed  along  the  bottom  of  the  display.  The  OK  button 
returns  the  user  to  the  Pairwise  Comparison  screen. 

7.  Direct  Input  of  Criteria  Weights  Screen 

This  screen  interface,  displayed  as  a  result  of  selecting 
the  second  radio  button  on  the  Prioritization  of  Evaluation 
Criteria  screen,  allows  the  user  to  input  directly  his 
evaluation  weighing  of  criteria  (see  Figure  25) .  Each  level 
of  criterion  are  intended  to  cycle  through  for  his  evaluation. 
Individual  weights  can  be  directly  typed  into  the  text  box  or 
manipulated  via  a  sliding  bar  adjacent  to  the  criteria.  The 
Enter  button  accepts  data  and  the  next  level  of  criteria  (if 
applicable)  are  displayed  until  all  criterion  have  been 
weighted.  The  Cancel  button  returns  the  user  to  the 
Prioritization  of  Evaluation  Criteria  screen. 
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Figure  24.   Priority  Vector  Graph  Screen 
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Figure  25.   Direct  Input  of  Criteria  Weights  Screen 


56 


E.   ALTERNATIVES  EVALUATION  MODULE 

Building  on  the  previous  module  of  Criteria 
Prioritization,  the  Alternatives  Evaluation  module  allows  the 
user  to  prioritize  the  problem  alternatives  with  respect  to 
criterion  and  corresponds  to  the  fourth  process  in  the  Co-oP 
model  (see  page  20) .  Using  methods  of  Pairwise  Comparison, 
ELECTRE,  or  direct  evaluation,  the  user  evaluates  the 
alternatives  as  identified  by  the  group.  This  module 
maintains  the  design  considerations  for  screen  interface  as 
presented  in  the  previous  module,  and  thus  utilizes  many  of 
the  screen  interfaces  already  presented,  with  minor 
modifications.  This  module  consists  of  seven  dialogue  boxes 
and  three  interactive  interfaces.  Additional  miscellaneous 
screens  with  be  discussed  in  the  final  section. 

1.  Evaluation  of  Alternatives  Screen 

This  screen  interface  is  of  the  same  format  and  function 
as  the  Prioritization  of  Evaluation  Criteria  screen  (see  page 
47) .  The  only  difference  being  the  addition  of  four  methods 
of  ranking  alternatives  (see  Figure  26)  .  All  functions  and 
controls  are  intended  to  perform  in  the  same  manner. 

2 .  Pairwise  Comparison  Screen 

This  screen,  with  two  modifications,  performs  the  same 
function  as  the  Pairwise  Comparison  screen  as  presented  in 
section  D  (see  page  47) .  Instead  of  comparing  criteria,  this 
interface  allows  the  user  to  compare  two  alternatives  with 
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Figure  26.   Evaluation  of  Alternatives  Screen 
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respect  to  a  single  criterion.  This  screen  adds  an  additional 
text  line  identifying  that  criterion  (see  Figure  27)  .  The 
user  evaluates  the  matrix  as  previously  described,  going 
through  each  criteria  and  looping  through  all  three  possible 
layers,  if  applicable,  until  all  criteria  have  been  used. 

3.  Modification  Technique  Screen 

This  screen  is  the  same  interface  as  utilized  in  the 
Criteria  Prioritization  Module.  As  previously  presented,  it 
allows  the  user  to  either  update  the  matrix  directly  or  select 
individual  alternatives  and  criteria  to  selectively  modify 
(see  section  D.3.). 

4.  Alternative  Modification  Screen 

This  screen  interface  performs  the  same  functions  as 
the  Criteria  Modification  screen  (see  page  51)  .  The  only 
additional  item  is  the  inclusion  of  a  combo  box  for  the  user 
to  select  the  criteria  the  two  alternatives  are  being  compared 
against  (see  Figure  28) . 

5.  Statistical  Evaluation  Screen 

This  screen  performs  the  same  function  as  in  the  Criteria 
Prioritization  Module  (see  page  51) .  Statistical  data 
regarding  the  matrix  is  presented  to  the  user  if  requested. 

6.  Priority  Vector  Graph  Screen 

This  screen  interface  with  one  modification  performs  the 
same  function  as  the  Priority  Vector  Graph  Screen  in  the 
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Figure  27.   Pairwise  Comparison  Screen 
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previous  module  (see  page  51)  .  The  only  additional 
information  is  the  display  of  criteria  in  which  the  matrix  is 
being  utilized  for  comparison  (see  Figure  29)  .  This  interface 
will  change  in  conjunction  with  the  Pairwise  Comparison 
criteria  update. 

7.  Evaluation  of  Alternatives  Using  Electre  Screen 
This  screen  interface  allows  the  user  to  compare  decision 

alternatives  based  on  well  defined  criteria  preferences.  The 
user  is  interactively  queried  to  evaluate  an  alternative  based 
on  weights  assigned  to  the  criteria  (see  Figure  30) .  The  user 
is  looped  through  each  alternative  and  is  evaluated  for  each 
criterion.  The  user  may  enter  values  directly  through  a  text 
box  or  manipulate  the  sliding  box  which  changes  the  weighted 
values  accordingly.  The  Enter  button  accepts  current  values 
and  upon  completion  of  all  entries  is  hidden  to  display  the 
complete  Alternative  Evaluation  screen  table.  Cancel  returns 
the  user  to  the  Evaluation  of  Alternatives  screen.  The  Help 
button  is  intended  to  provide  an  overview  text  description  of 
data  entry. 

8.  Alternative  Evaluation  Screen 

This  screen  interface  receives  inputs  from  the  Evaluation 
of  Alternatives  Using  Electre  screen  and  displays  them  to  the 
user  in  tabular  format  (see  Figure  31)  .  This  table  may  be 
edited  by  the  user  directly.   The  Enter  button  displays  the 
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Figure  28.   Alternative  Modification  Screen 
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Figure  29.   Priority  Vector  Graph  Screen 
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Figure   31.      Alternative  Evaluation  Screen 
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Matrix  Selection  screen  and  the  Cancel  button  returns  the  user 
to  the  Evaluation  of  Alternative  screen.  The  Help  button  is 
intended  to  display  an  overview  of  tabular  functions. 

9 .   Direct  Individual  Evaluation  Screen 

This  interface  allows  the  user  to  directly  input 
alternative  preferences  based  on  criteria.  Alternatives  are 
displayed  and  the  user  either  enters  a  weighted  value  directly 
via  a  text  box  next  to  the  alternative  or  he  manipulates  the 
sliding  bar  corresponding  to  that  alternative  (see  Figure  32) . 
Data  is  entered  until  all  criteria  have  been  evaluated.  A 
corresponding  normalized  priority  vector  is  displayed  for  the 
users  reference.  The  Enter  button  accepts  data  and  enters  the 
next  criterion.  Upon  completion  the  user  is  returned  to  the 
Main  Screen.  The  Cancel  button  returns  the  user  to  the 
Evaluation  of  Alternatives  screen.  The  Help  button  is 
intended  to  display  a  summary  of  required  inputs. 
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F.  DIRECT  INDIVIDUAL  EVALUATION  MODULE 

This  module  may  be  substituted  for  the  Criteria 
Prioritization  and  Alternatives  Evaluation  steps.  If  the  user 
chooses  to  evaluate  the  alternatives  directly  without 
utilizing  any  of  the  available  decision  support  models  he  has 
the  option  of  choosing  this  step.  The  module  itself  only 
consists  of  one  screen  interface  (see  Figure  33) .  Up  to  15 
alternatives  are  presented  and  the  user  may  enter  his  own 
weight  factor,  either  directly  in  a  text  box  or  manipulating 
the  associated  sliding  box.  Normalized  priority  vectors  are 
displayed  for  the  users  information.  The  Enter  button  accepts 
user  input  and  the  Cancel  button  returns  the  user  to  the  Main 
screen.  The  Help  button  is  provided  to  present  a  text  outline 
of  the  current  process. 

G.  COMPUTATION  OF  GROUP  DECISION  MODULE 

This  module  consists  of  three  screen  displays,  one  simple 
input  dialogue  box  and  three  output  screens.  The  purpose  of 
these  screen  interfaces  is  to  display  to  the  users  the  group 
problem  results  in  various  formats.  Help  formats  will  be 
discussed  in  general  in  the  miscellaneous  screen  section. 

1.   Computation  of  Group  Results  Screen 
This  screen  interface  allows  the  user  to  select  both  the 
group  problem  and  group  norm  from  combo  boxes  (see  Figure  34) . 
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This  input  is  used  in  determining  group  results. 
Additionally,  the  current  user  is  asked  to  enter  his  name 
which  will  then  prompt  a  password  screen  in  order  to  verify 
the  user  is  part  of  the  group  norm.  If  he  is,  he  may  then 
select  various  output  formats  using  the  appropriate  radio 
button  selection.  The  Enter  button  accepts  user  button 
selection  and  displays  the  corresponding  screen.  The  Cancel 
button  returns  the  user  to  the  Main  Co-oP  screen. 

2 .  Cardinal  Rankings  Screen 

This  screen  serves  to  display  individual  group  members 
decision  results  to  the  group.  This  broadcasting  of 
individual  results  is  subject  to  restrictions  as  set  forth  in 
the  group  norm  module.  The  current  user  selects  via  a  combo 
box  the  member  whose  results  he  desires  to  see  (see  Figure 
35)  .  The  alternatives  along  with  corresponding  weight  factors 
are  displayed  as  a  list.  The  OK  button  returns  the  user  to 
the  Computation  of  Group  Decision  screen.  The  Cancel  button 
returns  the  user  to  the  Main  Co-oP  screen. 

3 .  Ordinal  Rankings  Screen 

This  screen  interface  functions  similarly  to  the  Cardinal 
Ranking  screen.  Users  select  individual  group  members  to  view 
the  results  of  their  rankings  (see  Figure  36) .  They  may  view 
several  different  group  members  alternative  rankings  by 
selecting  different  names  from  the  combo  box.  Alternatives 
are  ranked  ordinally  in  list  format.   The  OK  button  returns 
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Figure  35.   Cardinal  Rankings  Screen 
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the  user  to  the  Computation  of  Group  Decision  screen.  The 
help  button  is  intended  to  amplify  information  presented. 

4.   Group  Results  Screen 

This  screen  interface  allows  the  user  to  view  the  groups 
final  results  (see  Figure  37) .  The  alternatives  are 
cardinally  with  four  adjacent  methods  of  ranking  as  follows: 

•  Rl  :  Maximum  Additive  Ranking 

•  R2  :  Maximum  Multiplicative  Ranking 

•  R3  :  Maximum  Sum  of  Outranking  Relations 

•  R4  :  Minimum  Sum  ot  the  Ranks 

These  methods  would  be  readily  available  in  the  help  text. 
The  OK  button  returns  the  user  to  the  Computation  of  Group 
Decision  screen. 

H.   IDENTIFY  NEGOTIABLE  ALTERNATIVES  MODULE 

Although  currently  not  available  as  an  interface  this 
modules  intention  is  to  help  the  group  MCDM  analyze  and 
possibly  resolve  negotiation  differences  [Ref .  l:p.  62] .  The 
Negotiable  Alternative  Identifier  (NAI)  is  a  proposed 
algorithm  support  decision  makers  analyze  differences  when 
techniques  of  aggregation  of  differences  fail  to  find  a 
unanimous  decision.  It  is  based  on  a  three  step 
expansion/contraction/intersection  mechanism  that  attempts  to 
optimize  a  solution. 
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I.   MISCELLANEOUS  SCREEN  INTERFACES 

There  are  several  additional  screen  layouts  that  may  be 
utilized  by  this  interface.  The  Help  screen  allows  for  either 
short  informative  text  message  or  an  extended  list  describing 
a  screen  function  or  model  requirements  (see  Figure  38)  . 
Exiting  the  Help  screen  via  an  OK  button  returns  you  to  the 
previously  displayed  screen.  Help  messages  should  be  short 
and  precise.  If  descriptive  outlines  are  used,  present  them 
in  a  numbered  step  process.  Error  messages  alert  the  user  to 
possible  problems  with  data  input  or  application  deficiency. 
As  in  the  case  of  Help  messages,  they  should  be  short  and  to 
the  point  with  the  OK  button  returning  the  user  to  the 
previously  displayed  screen  (see  Figure  39) . 
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IV.   SUMMARY  AND  RECOMMENDED  FUTURE  RESEARCH 

A.  SUMMARY 

The  intent  of  this  research  was  to  develop  a  graphical 
interface  for  Co-oP,  a  tool  in  support  of  group  decisions. 
The  proposed  Graphical  User  Interface  had  to  adapt  to  an 
already  established  educational  tool  and  maintain  the  Co-oP 
applications  framework  and  communication  parameters  in 
presenting  GDSS  models.  Utilizing  common  GUI  components  and 
building  on  general  principles  of  interface  design,  this  GUI 
attempts  to  present  a  complex  set  of  decision  support  tools 
that  encourage  user  interest  and  participation  through 
experimentation.  With  the  user  in  mind,  this  prototype  has 
mechanisms  that  allow  him  to  control  the  sequence  of  events, 
screen  designs  that  are  consistent  both  in  presentation  and 
control  devices,  and  focused  screen  designs  which  provide  a 
clear  conceptual  picture  of  decision  models  presented.  A 
major  goal  in  this  user  interface  design  was  to  allow  the  user 
to  be  in  command  of  the  application  and  not  let  the 
application  control  user  interaction. 

B.  RECOMMENDED  FUTURE  RESEARCH 

At  present  this  interface  is  a  graphical  screen  shell, 
providing  the  visual  interface  to  the  Co-oP  model.  Areas  that 
require  continued  research  and  implementation  include: 
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•  adding  code  to  support  screen  implementation  and  provide 
data  retrieval  and  error  checking 

•  adding  the  AHP  and  ELECTRE  algorithms 

•  conducting  extensive  user  surveys  through  application  test 
use  and  evaluation 

This  research  design  has  provided  the  basis  for  an  ideal 

Graphical  User  Interface.   The  design  framework  is  in  place 

but  requires  additional  research  and  development  in  order  to 

extend  and  explore  the  benefits  the  Co-oP  Multiple  Criteria 

Group  Decision  Making  model  and  expand  on  new  topics  it  may 

uncover. 
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